[CSS-in-JS] Convert EuiAvatar#5670
Conversation
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
| -webkit-box-pack: center; | ||
| -ms-flex-pack: center; | ||
| -webkit-justify-content: center; | ||
| justify-content: center; |
There was a problem hiding this comment.
Doesn't seem like we should need all this vendor prefixing. Investigating.
https://caniuse.com/flexbox
There was a problem hiding this comment.
Stylis is tracking; not sure it's worth doing something non-standard when it comes to prefixing.
There was a problem hiding this comment.
Just noting, also, that updating .browserslistrc to eliminate Safari 7 does not change the generated vendor prefixes.
src/components/avatar/avatar.tsx
Outdated
| css={[ | ||
| styles.euiAvatar, | ||
| styles[size], | ||
| styles[type], | ||
| isDisabled && styles.isDisabled, | ||
| color === 'plain' && styles.plain, | ||
| ]} |
There was a problem hiding this comment.
Interestingly, using an array inside the css prop will result in the component name getting used in the resulting class name. Definitely not documented anywhere I can see.
So just using "labelFormat": "[local]" config, we get a class name like css-{hash}-EuiAvatar. Or css-{hash}-s-space-EuiAvatar if other variants are in play. This seems good!
There was a problem hiding this comment.
Also, it's not important for this component, but order matters when composing styles in a css prop array: https://emotion.sh/docs/composition
For instance, if we were setting background-color in the isDisabled styles, the plain styles would "win" the specificity battle. This is largely helpful for our purposes but different from how the CSS specificity rules.
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
576d747 to
06694a1
Compare
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
|
Not sure if it matters, but should the CSS name still be mangled/uglified on the PR staging link? Here's what I'm seeing on https://eui.elastic.co/pr_5670/#/display/avatar: Mostly asking because from my understanding on the other PR, we were not mangling strings on prod? Or am I getting confused and that setting was on the EuiMark PR only? |
Whoops, sorry for the confusion. This PR is missing the |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
cchaos
left a comment
There was a problem hiding this comment.
A whole lotta comments/questions, but in general I love it. We can go over some of the more discussion-y questions in the sync.
779634c to
ea064fa
Compare
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
ea064fa to
7d3f7e9
Compare
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
1 similar comment
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
872615d to
020d12a
Compare
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
No. Unfortunately that just isn't how emotion (or styled-components) works. The whole point is to eliminate naming collisions and specificity overrides. They solved it by creating a unique class per style instance. Even if we used a workaround to pass classes to
We'll want to keep some inline styles for dynamic styles like generating a color based on content. This will dramatically reduce the number of generated classes.
Perhaps we have a separate function for subcomponents.
Math on px values does not work (we expected this). After the refactor to dedupe the sizing styles, the output is |
|
@thompsongl I'm ready to do a final review on this but can you pull in |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
It removed the size `-m` from the class☹️
Fixes class name output but is it worth it?
Adds a typically unecessary extra css`` wrapper but keeps the keys
There was a problem hiding this comment.
I pushed 3 commits which are 3 attempts to DRY out the sizing styles. The first was the most intuitive to me, but resulted in the size value (-m) no longer being output to the class name. So the next two were other attempts. I finalized on the third but the con is that it results in multiple css wrappers. I don't know what that might do to performance (if any) but it kind of hurts readability just slightly.
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
|
Sorry for the delayed responses; I completely missed the notification!
I think we can remove one layer of |
| s: css( | ||
| _avatarSize({ | ||
| size: euiTheme.size.l, | ||
| fontSize: euiTheme.size.m, | ||
| }) | ||
| ), |
There was a problem hiding this comment.
The css method can be called as just a normal function for cases like this. And _avatarSize can just return a normal string that will be accepted.
🎉
There was a problem hiding this comment.
Lets get some docs written down about this before we forget 🤔
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |
cchaos
left a comment
There was a problem hiding this comment.
🙌 Thank you for that wiki addition!
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5670/ |

Summary
EuiAvatarstyles from Sass to Emotioncssprop values for better class name output ([CSS-in-JS] ConvertEuiAvatar#5670 (comment))Checklist